fix: Preserve integer values in round() for large Int64 and UInt64 inputs by pchintar · Pull Request #22697 · apache/datafusion

pchintar · 2026-06-01T12:24:57Z

Which issue does this PR close?

Closes round() mishandles large Int64 and UInt64 values #22696 .

Rationale for this change

round() should not change integer values when the scale is non-negative, since no fractional digits need to be rounded.

Currently, core round() coerces large Int64 values through Float64, causing precision loss:

SELECT round(arrow_cast(9007199254740993, 'Int64'));

Before/Current Buggy Output:

9007199254740992.0

Expected:

9007199254740993

The Spark-compatible round() also fails for UInt64 values above i64::MAX even when the scale is non-negative:

SELECT round(arrow_cast(18446744073709551615, 'UInt64'));

Before/Current Buggy Output:

round: UInt64 value 18446744073709551615 exceeds i64::MAX and cannot be rounded

What changes are included in this PR?

Preserved integer inputs in core round() for non-negative scales instead of routing them through Float64.
Preserved UInt64 values in Spark-compatible round() when the scale is non-negative, avoiding unnecessary UInt64 -> i64 conversion.
Added SQLLogicTest coverage for:
- Int64 values above 2^53 in core round().
- UInt64::MAX in Spark-compatible round().
- Both one-argument and two-argument forms.

Are these changes tested?

Yes.

cargo fmt --all
git diff --check
cargo test -p datafusion-sqllogictest --test sqllogictests -- spark/math/round.slt
cargo test -p datafusion-functions round
cargo test -p datafusion-spark round

I also verified the core regression queries manually:

SELECT arrow_typeof(round(arrow_cast(9007199254740993, 'Int64'))),
       round(arrow_cast(9007199254740993, 'Int64'));

Result:

Int64 9007199254740993

SELECT arrow_typeof(round(arrow_cast(9007199254740993, 'Int64'), 2)),
       round(arrow_cast(9007199254740993, 'Int64'), 2);

Result:

Int64 9007199254740993

Are there any user-facing changes?

No.

kumarUjjawal · 2026-06-02T06:24:56Z

        // extra precision to accommodate potential carry-over.
        let return_type =
            match input_type {
+                input_type if is_integer_data_type(input_type) => input_type.clone(),


returns the integer type for all scales, but only non-negative scales are handled downstream. round(arrow_cast(125,'Int64'), -1) now fails, it returned 130.0 before this PR.

kumarUjjawal · 2026-06-02T06:26:34Z


            match (value_scalar, args.return_type()) {
+                (value_scalar, return_type)
+                    if is_integer_data_type(return_type) && dp >= 0 =>


only covers dp >= 0. For dp < 0 with an integer value, needs handler for negative scale

kumarUjjawal · 2026-06-02T06:28:42Z

+    }
+
    let arr: ArrayRef = match (value_array.data_type(), return_type) {
+        (input_type, return_type)


The no-op fast path requires decimal_places to be a non-negative scalar literal. When the scale is a column (or a negative literal), this guard is false and there's no other integer arm, so it hits exec_err!

CREATE TABLE t(v BIGINT, dp INT) AS VALUES (125,1),(125,-1); SELECT round(v, dp) FROM t; -- errored; worked (Float64) before this PR

kumarUjjawal · 2026-06-02T06:31:47Z

tests only cover non-negative scalar scale. There's no coverage for negative scale, column scale, or negative scale on a column

kumarUjjawal · 2026-06-02T06:34:00Z

+                (value_scalar, Float64)
+                    if is_integer_data_type(&value_scalar.data_type()) =>
+                {
+                    let value = ColumnarValue::Scalar(value_scalar.clone())
+                        .cast_to(&Float64, None)?;
+                    match value {
+                        ColumnarValue::Scalar(ScalarValue::Float64(Some(v))) => {
+                            let rounded = round_float(v, dp)?;
+                            Ok(ColumnarValue::Scalar(ScalarValue::Float64(Some(rounded))))
+                        }
+                        ColumnarValue::Scalar(ScalarValue::Float64(None)) => {
+                            Ok(ColumnarValue::Scalar(ScalarValue::Float64(None)))
+                        }
+                        _ => internal_err!(
+                            "Unexpected datatype after casting integer argument to Float64"
+                        ),
+                    }
+                }


This (value_scalar, Float64) if is_integer_data_type(value) arm and theround_integer_array_to_float64! macro + the eight (IntN, Float64) array arms are unreachable:

kumarUjjawal · 2026-06-02T06:34:21Z

cc @neilconway

pchintar · 2026-06-02T09:24:15Z

@kumarUjjawal Thnx for the review!

I've updated the implementation so that integer inputs now stay as integer types instead of being converted through Float64. This preserves large Int64 values that cannot be represented exactly as Float64.

I also added tests for the cases you mentioned:

negative decimal_places values (for example, round(125, -1))
column-valued decimal_places
large Int64 values above the exact Float64 range

Additionally, I updated the affected sqllogictest expectations since the plan output changed after removing the unnecessary cast to Float64.

I've also rerun the relevant tests and manually verified all these cases.

pchintar · 2026-06-02T10:43:49Z

@kumarUjjawal could you pls re-run the CI checks? thnx again

pchintar · 2026-06-02T10:59:13Z

@kumarUjjawal This failure seems to be unrelated to my code.

It failed before running DataFusion tests because GitHub Actions could not pull the Docker image:

docker pull amd64/rust
Get "https://registry-1.docker.io/v2/": context deadline exceeded

So this is a CI infrastructure/network failure, not a test failure perhaps?

kumarUjjawal · 2026-06-02T11:00:38Z

@kumarUjjawal This failure seems to be unrelated to my code.

It failed before running DataFusion tests because GitHub Actions could not pull the Docker image:
docker pull amd64/rust
Get "https://registry-1.docker.io/v2/": context deadline exceeded
So this is a CI infrastructure/network failure, not a test failure perhaps?

Yeah ignore this, it's Github issue

pchintar · 2026-06-02T11:03:03Z

Yeah ignore this, it's Github issue

So wdyt of my PR? is it good enough to be approved? or is it too early to tell?

kumarUjjawal · 2026-06-02T11:04:27Z

Yeah ignore this, it's Github issue

So wdyt of my PR? is it good enough to be approved? or is it too early to tell?

Will review tomorrow!

pchintar · 2026-06-02T11:05:19Z

Will review tomorrow!

Sure, thank you!

github-actions Bot added sqllogictest SQL Logic Tests (.slt) functions Changes to functions implementation spark labels Jun 1, 2026

pchintar force-pushed the round-large-integer-handling branch from e565975 to 7832c0c Compare June 1, 2026 13:58

kumarUjjawal reviewed Jun 2, 2026

View reviewed changes

Preserve integer precision in round()

97a7294

pchintar force-pushed the round-large-integer-handling branch from 7832c0c to 97a7294 Compare June 2, 2026 09:13

Conversation

pchintar commented Jun 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Which issue does this PR close?

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Uh oh!

kumarUjjawal Jun 2, 2026

Choose a reason for hiding this comment

Uh oh!

kumarUjjawal Jun 2, 2026

Choose a reason for hiding this comment

Uh oh!

kumarUjjawal Jun 2, 2026

Choose a reason for hiding this comment

Uh oh!

kumarUjjawal Jun 2, 2026

Choose a reason for hiding this comment

Uh oh!

kumarUjjawal Jun 2, 2026

Choose a reason for hiding this comment

Uh oh!

kumarUjjawal commented Jun 2, 2026

Uh oh!

pchintar commented Jun 2, 2026

Uh oh!

pchintar commented Jun 2, 2026

Uh oh!

pchintar commented Jun 2, 2026

Uh oh!

kumarUjjawal commented Jun 2, 2026

Uh oh!

pchintar commented Jun 2, 2026

Uh oh!

kumarUjjawal commented Jun 2, 2026

Uh oh!

pchintar commented Jun 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

pchintar commented Jun 1, 2026 •

edited

Loading

pchintar commented Jun 2, 2026 •

edited

Loading